\section{Discussion and Related Work}
\label{sec:RW}

{
\begin{small}
\begin{table*}[t]

%\begin{tabularx}{p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm}}

\begin{tabularx}{\textwidth}{X X X X X X} % 6 columns

\toprule 


%{\bf } &  \alc{ {\bf FPL}} & \alc{{\bf PU}} & \alc{{\bf PP}} & \alc{{\bf SRC}}& \alc{{\bf OS}} & \alc{{\bf RS}} & \alc{{\bf PS}} & \alc{{\bf CR}} \\ 

 &  \alcx{\bf DM} &  \alc{\bf SM} & \alc{\bf CS} &\alc {\bf SC} & \alc{\bf CG} \\ 

\midrule 

{\bf SecureUML}\cite{Basin2006a}&\cc{UML}&\cc{Profiles}&\cc{OCL}&\cc{AC}&\yes\\
{\bf UMLsec}\cite{Jan2002} & \cc{UML}&\cc{Profiles}&\no&\cc{C,IF,AC}&\no\\
{\bf secureMDD}\cite{moebius_securemdd:_2009}& \cc{UML} & \cc{Profiles} &\no & \cc{AC}&\yes \\
{\bf ModelSec}\cite{sanchez_modelsec}& \cc{UML} & \cc{SecML}&\kinda & \cc{MC}&\yes\\
 {\bf SECTET}\cite{Breu2007a}& \cc{SE-UML} & \cc{Profiles}&\cc{SE-PL}&\cc{AC}&\kinda\\
 {\bf XACML}\cite{XACML}& \no &\cc{XACML} & \cc{XACML} & \cc{AC,OB}&\no\\

{\bf S@R }& \cc{UML}&\cc{S@R} & \cc{S@R}&\cc{AC,OB}&\yes\\

\midrule
\multicolumn{6}{c}{AC: Access Control, C: Confidentiality, }\\
\multicolumn{6}{c}{ IF: Information Flow, OB: Obligations, MC: Multiple Concerns}\\

\midrule

\multicolumn{6}{c}{ {\bf DM}: System Modeling, {\bf SM}: Security Modeling, {\bf CL}: Contextual Security}\\

\multicolumn{6}{c}{  {\bf SC}: Security Concerns, {\bf CG}: Code Generation} \\
%\multicolumn{9}{c}{ }\\

\bottomrule 

%\textit{•}
\end{tabularx} 
\bigskip
   \bigskip
\caption{Comparison of \SAR with Existing MDS approaches}
\label{table:stateOfTheArt}
\end{table*}
\end{small}
}

Since the seminal contributions of Lodderstedt and Basin with Secure\textsc{Uml} \cite{Lodderstedt2002}, and J\"{u}rgens with \textsc{Uml}Sec \cite{Jan2002} back in 2002, model-based development of secure systems has been an active research area. In Table \ref{table:stateOfTheArt}, we compare several contributions with respect to several dimensions: system (DM) and security modeling (SM); contextual security (CS); security concerns (SC) (i.e. what kind of security properties can be expressed); and code generation (CG). %The rest of the section contrasts these approaches with ours. %Since runtime policy updating and security rule violation monitoring is not, to the best of our knowledge, present in any of these approaches, we do not discuss this dimension.

\medskip\noindent
\textbf{Domain \& Security Modeling.} \textsc{Uml} is the most common way to define the target application domain, as shown in the first column of Table~\ref{table:stateOfTheArt}. \textsc{UML}-based approaches annotate the business \textsc{Uml} model with their security requirements. Conceptually, our approach is different since we introduce the \SAR DSL to specify security requirements and their mapping to target systems. One advantage of our approach is that it cleanly separates security from system specification making a true separation of concerns, as opposed to the use of \textsc{OCL} constraints to specify contextual policies when \textsc{Uml} profiles are used. Note that \textsc{Xacml}  does not assume any specific domain modeling language and, therefore, it does not provide means to systematically integrate security mechanisms for enforcing \textsc{Xacml} policies in targeted systems. % with profiles. Therefore, our approach better satisfies the separation of concerns principle. 

\medskip\noindent
\textbf{Expressivity} of Security Languages is a major challenge since it is necessary to cover the specification of many practical security concerns. 
Many systems today have security requirements that go beyond access control, as recognized by Basin, Clavel and Egea in \cite{Basin2011} where they pointed out the need to add support for obligations. 
To the best of our knowledge, \SAR is the first \textsc{Dsl} that supports management and enforcement of both authorizations and obligations. The specification of obligations is supported in \textsc{Xacml}~\cite{XACML}. However, obligations in \textsc{Xacml} are syntactic elements without formal semantics. Furthermore, \textsc{Xacml} does not provide management and enforcement support for obligations.
	
	%\item[\emph{Contextual Security.}] If some approaches allow the specification of runtime conditions, security rules are usually expressed using a mix of \textsc{Uml} annotations and \textsc{Ocl}-based constraints. However, \textsc{Ocl} can only address limited runtime specifications: for example, expressing the fact that an instance field's value participates in a method call as an effective parameter is not an easy task. Contrasting with these approaches, we handle runtime conditions in a compartmented way: an abstracted representation of the runtime is maintained, and the security officer designs requirements using a pattern-like language for specifying contexts and operations participating in policy actions. The matching, at runtime, ensures a dynamic evaluation of the requirements. 
	
	%\item[\emph{Security Concerns.}] Very few approaches can handle several security properties. With \textsc{Uml}Sec, Jan \cite{Jan2002} supports confidentiality, information flow and access control. %ModelSec \cite{sanchez_modelsec} seems promising: the \textsc{Dsl} at the core of the language can easily be extended with new security concerns.
%\end{description}


\medskip\noindent
\textbf{Violation Monitoring \& Policy Runtime Updating.} Runtime policy updating and security rule violation monitoring are not, to the best of our knowledge, present in any of the current approaches.  

\medskip\noindent
\textbf{Security Infrastructure.} Despite the use of automated transformations in \textsc{Mds}, it is still difficult to enable full code generation from high-level requirements. Secure\textsc{Uml} \cite{Basin2006a} supports the generation of secure systems for two target architectures (Enterprise JavaBeans and Microsoft DotNet), but the generating mechanism relies on pre-existing security mechanisms. In \textsc{Sectet}, the information relevant for authorizations are specified using the tool's language, and transformed into \textsc{Xacml} specifications. In \cite{sanchez_modelsec}, security and business are composed into a model from which Java code is generated. 
Our approach generates Prolog code from security policies defined within \SAR, whereas the rest (i.e., aspects monitoring and policy interpretation) is application-independent.

%In our approach, code generation and adaptation appears in %two areas: first, the aspectJ layer monitoring the application is automatically tailored for the application on the basis of the static mappings to filter out information communicated to the PDP; and second, 
%the generation of security policies from the security model into Prolog. The remainder of our security infrastructure such as aspects monitoring the application and the policy engine interpreting the security policy are application-independent.


